For a computer system, the occurrence of an event need to be communicated to the computer system's “clients.” These clients are typically applications and other entities such as executable code modules and libraries that reside on the computer system. For a computer system such as a handheld device, these clients are typically third party applications. For event notification, a prior art approach is for an Event Manager to iterate through a list of clients to be notified. Specifically, for a client on the notification list, a specified routine inside the client is called. Parameters that indicate which event has occurred are passed into the specified routine.
However, this prior art approach of notifying clients is problematic in its response to an OS crash. Specifically, one of the clients may cause an OS crash in response to being notified of the event. Then, the computer system implements crash recovery steps such as a device reset and an OS reboot. The device reset may trigger the event notification process again that iterates through the client list again for notifying these clients. As such, the client that caused the OS crash prior to the OS crash could cause the OS to crash again. Consequently, the computer system could undesirably execute an infinite loop comprising steps of notification, crash, crash recovery, then back to notification, crash, crash recovery, ad infinitum.
Referring now to FIG. 1, a flow chart 10 is shown outlining steps performed in the prior art approach. These steps are performed to notify clients of an occurred event, and moreover recover from an OS crash in response to the OS crash. Flow chart 10 can be implemented as instruction code executed on a processor of a computer system. As understood herein, although the computer system is preferably a handheld device, a more generic computer system can also be used.
In step 5, a not-yet notified client on a notification list is selected to be notified about an occurred event.
In step 15, a specified routine is called within the selected client to begin notification of the occurred event to the client.
In step 20, parameters are passed into the specified routine. These parameters indicate to the client what event has occurred.
In query step 25, if the OS crashes, then step 35 is performed. Otherwise, if the OS does not crash, then step 30 is performed.
In query step 30, in response to the OS running normally after the notification to the client, a check is performed to see if all other clients on the entire notification list are notified about the occurred event. If all clients are notified, then flow chart 10 terminates. Otherwise, step 35 is performed.
In step 35, another not-yet notified client on the notification list is selected. Specifically, the newly selected client on the notification list is targeted to receive notification of the occurred event. Steps 15, 20, 25, 30 and 35 are then repeated for this newly selected client.
If in query step 25 the OS is found to crash, then OS crash recovery steps 40 and 45 are performed in response to the OS crash. In step 40, the device is reset. Then in step 45, the OS is rebooted.
In step 50, the computer system is returned to running normally. Moreover, because of the device reset, the event notification (starting from step 5) begins once again. Problematically, this notification process again notifies the client that had triggered the OS crash. In turn, the same client is likely to cause the OS to crash again. Thus, the computer system might indefinitely repeat the loop comprising the steps of 5, 15, 20, 25, 40, 45 and 50, then back again to 5, ad infinitum.